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Protocol Analysis for Extensions to RIP to Support Demand Circuits 
Status of this Memo 
This document provides information for the Internet community. This 
document does not specify an Internet standard of any kind. 
Distribution of this document is unlimited. 
Abstract 
As required by Routing Protocol Criteria [1], this report documents 
the key features of Routing over Demand Circuits on Wide Area 
Networks - RIP [2] and the current implementation experience. 
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1. Protocol Documents 
"Extensions to RIP to Support Demand Circuits" [2] suggests an 
enhancement to the "Routing Internet Protocol" (RIP) [3] and "RIP-2" 
[4] to allow them to run more cost-effectively on Wide Area Networks 
(WANS). Network management extensions for Demand RIP are described 
in RIP Version 2 MIB Extensions [5]. 
2. Applicability 


Demand RIP requires that there is an underlying mechanism for 
determining unreachability in a finite predictable period. 


The demand extensions to RIP are particularly appropriate for WANs 


where the cost - either financial or packet overhead - would make 
periodic transmission of routing (or service advertising) updates 
unacceptable: 

o Connection oriented Public Data Networks - for example X.25 packet 


switched networks or ISDN. 


o Point-to-point links supporting PPP link quality monitoring or 
echo request to determine link failure. 
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A demand RIP implementation runs standard RIP on Local Area Networks 
(LANs) allowing them to interoperate transparently with 
implementations adhering to the original specifications. 


3. Key Features 


The proposal shares the same basic algorithms as RIP or RIP-2 when 
running on LANs or fixed point-to-point links; Packet formats, 


broadcast frequency, triggered update operation and database timeouts 


are all unmodified. 


The new features operate on WANs which use switched circuits on 
demand to achieve intermittent connectivity. Instead of using 


periodic ‘broadcasts’, information is only sent as triggered updates. 


The proposal makes use of features of the underlying connection 
oriented service to provide feedback on connectivity. 


3.1 Triggered Updates 


Updates are only sent on the WAN when an event changes the routing 
database. Each update is retransmitted until acknowledged. 
Information received in an update is not timed out. 


The packet format of a RIP response is modified (with a different 
unique command field) to include sequence and fragment number 


information. An acknowledgement packet is also defined. 


3.2 Circuit Manager 


The circuit manager running below the IP network layer is responsible 


for establishing a circuit to the next hop router whenever there is 


data (or a routing update) to transfer. After a period of inactivity 


the circuit will be closed by the circuit manager. 


If the circuit manager fails to make a connection a circuit down 
indication is sent to the routing application. The circuit manager 
will then attempt at (increasing) intervals to establish a 
connection. When successful a circuit up indication is sent to the 
routing application. 


3.3 Presumption of Reachability 
In a stable network there is no requirement to propagate routing 


information on a circuit, so if no routing information is (being) 
received on a circuit it is assumed that: 
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o The most recently received information is accurate. 


o The intervening path is operational (although there may be no 
current connection). 


If the circuit manager determines that the intervening path is NOT 
operational routing information previously received on that circuit 
is timed out. It is worth stressing that it can be ANY routed 
datagram which triggers the event. 


When the circuit manager re-establishes a connection, the application 
exchanges full routing information with its peer. 


3.4 Routing Information Flow Control 


If the circuit manager reports a circuit as down, the routing 
application is flow controlled from sending further information on 
the circuit. 


To prevent transmit queue overflow and also to avoid ’predictable’ 
circuit down messages, the routing application can also optionally 
limit the rate of sending routing messages to an interface. 


4. Implementations 


At this stage there is only believed to be one completed 
implementation. 


The Spider Systems’ implementation supports all the features outlined 
for IP RIP-1, IPX RIP and IPX SAP. RIP-2 is not currently supported. 
It has been tested against itself on X.25 and ISDN WANs. It has also 
been tested in operation with various router and host RIP-1, IPX RIP 

and IPX SAP implementations on Ethernet LANs. 


Two other Novell-only implementations are known to be under 
development. 


5. Restrictions 
Demand RIP relies on the ability to place a call in either direction. 
Some dialup services - for example DTR dialing - allow calls to be 
made in one direction only. 
Demand RIP can not operate with third-party advertisement of routes 


on the WAN. The next hop IP address in RIP-2 should always be 
0.0.0.0 for any routes advertised on the WAN. 
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6. Security Considerations 


Security is provided through authentication of the logical and 


physical address of the sender of the routing update. Incoming call 
requests are matched by the circuit manager against a list of 
physical addresses (used to make outgoing calls). The routing 


application makes a further check against the logical address of an 
incoming update. 


Additional security can be provided by RIP-2 authentication [2] where 
appropriate. 
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